There are a variety of systems for authenticating a user to a computer and/or computer network. For example, to log on to a computer, a user typically types in a password.
Other known authentication systems require two factors of identification. One such system is the RSA SECURID system by RSA, The Security Division of EMC Corporation of Hopkinton, Mass. In general, this system requires a user to input an alpha-numeric Personal Identification Number (PIN) and data from a device in form of an authentication token in possession of the user. A server verifies the user PIN and the security data from the token, which is known by the server. The RSA SECURID system is generally described in U.S. Pat. No. 4,720,860 to Weiss, which is incorporated herein by reference.
Typically, an authentication system requires the sharing of some information with an authentication server, where this information is typically not known to other entities, and where this information allows the generation and verification of at least parts of some authentication string. This authentication string commonly also includes, or is a function of, some information that is memorized by the owner of the token and also stored on the server. The authentication maybe interactive, e.g., a challenge-response format, or non-interactive, e.g., no information is sent from the server to the user/token in order to complete the generation of the authentication string. The information that constitutes the authentication attempt may be sent over a potentially insecure communication link, such as a wireless or wired network.
In some access control systems, such as those found in network file servers, identify an accessing entity by a user identifier (user ID) and/or by membership in one or more named groups. The user ID is optionally dependent on an OS executing on (or on behalf of) the accessing entity, and thus a user ID provided by an OS that is trusted is distinguishable from a user ID provided by an OS that is not trusted. Access is explicitly granted and/or denied for resources, such as files, by enumerated “access rights” for users and/or for groups.
Typically, when a user (having a specific user ID, and being a member of one or more named groups) accesses a resource, such as a file, access is granted if the user ID is permitted access to the resource, or if a group to which the user belongs is permitted access to the resource. In some cases, access to a resource is controlled by a permission list for the resource, each element of the permission list including a user ID and/or a group name along with access rights for the user ID and/or group. The access rights allow or deny various types of access, such as read access, write access, delete access, or all access. Rules and/or policies may control how access rights are resolved, including how conflicting access rights are resolved.
An authentication mechanism may enforce additional requirements before access from a client computer (and/or from a user) to a resource is granted. For example, a requirement may be enforced that an agent (e.g. a software program) be installed on the client computer before access to sensitive files is allowed. Requiring installation of an agent may enable enforcement of usage restrictions, such as by disabling access to some or all resources from the client computer and/or from a specific user.